New CAEP event - Risk level change event #205
Conversation
Risk level change event
|
|
||
| ### Event Specific Claims {#risk-level-change-event-specific-claims} | ||
| The following optional claims MAY be present in a Session Presented event: | ||
|
|
There was a problem hiding this comment.
Could we add a field that describes the type of risk? You mention in your example user risk and device risk. What if we had a field called risk_type whose values were an enum:
- DEVICE
- USER
- ACCOUNT
- OTHER
There may be other values that we should include in this enum as well.
There was a problem hiding this comment.
@FragLegs I thought we could drive the type using the subject claim. With a single enum it would be hard to flag a single risk event if it applies to more than 1 entity like USER + DEVICE etc.
Co-authored-by: Shayne Miel (he/him) <[email protected]>
| : REQUIRED, JSON string indicates the reason that contributed to the risk level changes by the Transmitter. Overall this is an OPTIONAL claim, but marked as REQUIRED for Risk Level Change to indicate reasons behind the risk level change. | ||
|
|
||
| current_level | ||
| : REQUIRED, JSON string indicates the current level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH |
There was a problem hiding this comment.
Mandating the use of a LOW, MEDIUM, HIGH for risk levels may be too restricted for some usage. Some Companies may want to use a numeric range (e.g., 1-5 or 1-10) instead without needing to map it into LOW, MEDIUM, HIGH range.
One option is to add some kind of an optional "risk type" or "risk system" that may indicates to receivers how the risk is calculated and how it is being represented
There was a problem hiding this comment.
Assurance level change uses namespace, but in that example, there are standardized ways of representing levels.
In this case, I feel even the numeric system will be subjective, it will not help bring standardization.
Another option is to plainly define a score as an optional attribute that could satisfy your use case, but I believe that could be solved by adopting #221
|
The Risk level change event can be used by implementers as a "catch all" event. For example, an receiver could decide to use Risk level change instead of implementing the CAEP events. If we have a Risk level change event, which is prescriptive, we'd allow implementers to go the easy route and implement ONLY Risk level change event. Is that a behavior we want to encourage? As we discussed today CAEP events are descriptive, while Risk event is prescriptive. I don't see prescriptive and descriptive events coexist in the same spec. My suggestion is to wait with adding this event to the final spec. |
This event is the same as any other event in the CAEP spec, and it is NO WAY prescriptive. The Reciver may decide to do NOTHING on the risk being HIGH, same way as they chose to ingnore existing Session Revoked or Credential Change events. Whether and how organizations respond to any of the CAEP events is completely dependent on their risk tolerance levels. The event can describe what led to Tx raising or reducing the risk and description around that, this is very flexible mechanism to share the risks with vendors. |
The Risk level change event does not prescribe what to do, it just augments different security events into the Risk level change event. The question is do we need to have an event that factors other CAEP events to come up with Low/Medium/High or a Tx can just use the existing CAEP events. If there are other events that Risk level change is factoring, can we just add those events as stand-alone events to the CAEP spec? |
As discussed in the call, risk indicators are a function of the Tx maturity. Risk calculations are outside the scope of this specification. Risk may encompass things described outside CAEP and RISK specs. You are free to propose any new events that describe your usecases. This event is standalone and represents risk as a first-class object to be shared with the co-operating parties. There is no implicit dependency on presence or absence of other events. |
New CAEP event - Risk level change event
Closes #200
Removed
ipsclaim from the event and created #201 to handle it separately for all CAEP events